<!DOCTYPE html>
<html>
<!-- Created by GNU Texinfo 7.1, https://www.gnu.org/software/texinfo/ -->
<head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
<!-- Copyright © 1988-2023 Free Software Foundation, Inc.

Permission is granted to copy, distribute and/or modify this document
under the terms of the GNU Free Documentation License, Version 1.3 or
any later version published by the Free Software Foundation; with the
Invariant Sections being "Funding Free Software", the Front-Cover
Texts being (a) (see below), and with the Back-Cover Texts being (b)
(see below).  A copy of the license is included in the section entitled
"GNU Free Documentation License".

(a) The FSF's Front-Cover Text is:

A GNU Manual

(b) The FSF's Back-Cover Text is:

You have freedom to copy and modify this GNU Manual, like GNU
     software.  Copies published by the Free Software Foundation raise
     funds for GNU development. -->
<title>Processor pipeline description (GNU Compiler Collection (GCC) Internals)</title>

<meta name="description" content="Processor pipeline description (GNU Compiler Collection (GCC) Internals)">
<meta name="keywords" content="Processor pipeline description (GNU Compiler Collection (GCC) Internals)">
<meta name="resource-type" content="document">
<meta name="distribution" content="global">
<meta name="Generator" content="makeinfo">
<meta name="viewport" content="width=device-width,initial-scale=1">

<link href="index.html" rel="start" title="Top">
<link href="Option-Index.html" rel="index" title="Option Index">
<link href="index.html#SEC_Contents" rel="contents" title="Table of Contents">
<link href="Insn-Attributes.html" rel="up" title="Insn Attributes">
<link href="Delay-Slots.html" rel="prev" title="Delay Slots">
<style type="text/css">
<!--
a.copiable-link {visibility: hidden; text-decoration: none; line-height: 0em}
div.example {margin-left: 3.2em}
span:hover a.copiable-link {visibility: visible}
ul.mark-bullet {list-style-type: disc}
-->
</style>


</head>

<body lang="en">
<div class="subsection-level-extent" id="Processor-pipeline-description">
<div class="nav-panel">
<p>
Previous: <a href="Delay-Slots.html" accesskey="p" rel="prev">Delay Slot Scheduling</a>, Up: <a href="Insn-Attributes.html" accesskey="u" rel="up">Instruction Attributes</a> &nbsp; [<a href="index.html#SEC_Contents" title="Table of contents" rel="contents">Contents</a>][<a href="Option-Index.html" title="Index" rel="index">Index</a>]</p>
</div>
<hr>
<h4 class="subsection" id="Specifying-processor-pipeline-description"><span>17.19.9 Specifying processor pipeline description<a class="copiable-link" href="#Specifying-processor-pipeline-description"> &para;</a></span></h4>
<a class="index-entry-id" id="index-processor-pipeline-description"></a>
<a class="index-entry-id" id="index-processor-functional-units"></a>
<a class="index-entry-id" id="index-instruction-latency-time"></a>
<a class="index-entry-id" id="index-interlock-delays"></a>
<a class="index-entry-id" id="index-data-dependence-delays"></a>
<a class="index-entry-id" id="index-reservation-delays"></a>
<a class="index-entry-id" id="index-pipeline-hazard-recognizer"></a>
<a class="index-entry-id" id="index-automaton-based-pipeline-description"></a>
<a class="index-entry-id" id="index-regular-expressions"></a>
<a class="index-entry-id" id="index-deterministic-finite-state-automaton"></a>
<a class="index-entry-id" id="index-automaton-based-scheduler"></a>
<a class="index-entry-id" id="index-RISC"></a>
<a class="index-entry-id" id="index-VLIW"></a>

<p>To achieve better performance, most modern processors
(super-pipelined, superscalar <abbr class="acronym">RISC</abbr>, and <abbr class="acronym">VLIW</abbr>
processors) have many <em class="dfn">functional units</em> on which several
instructions can be executed simultaneously.  An instruction starts
execution if its issue conditions are satisfied.  If not, the
instruction is stalled until its conditions are satisfied.  Such
<em class="dfn">interlock (pipeline) delay</em> causes interruption of the fetching
of successor instructions (or demands nop instructions, e.g. for some
MIPS processors).
</p>
<p>There are two major kinds of interlock delays in modern processors.
The first one is a data dependence delay determining <em class="dfn">instruction
latency time</em>.  The instruction execution is not started until all
source data have been evaluated by prior instructions (there are more
complex cases when the instruction execution starts even when the data
are not available but will be ready in given time after the
instruction execution start).  Taking the data dependence delays into
account is simple.  The data dependence (true, output, and
anti-dependence) delay between two instructions is given by a
constant.  In most cases this approach is adequate.  The second kind
of interlock delays is a reservation delay.  The reservation delay
means that two instructions under execution will be in need of shared
processors resources, i.e. buses, internal registers, and/or
functional units, which are reserved for some time.  Taking this kind
of delay into account is complex especially for modern <abbr class="acronym">RISC</abbr>
processors.
</p>
<p>The task of exploiting more processor parallelism is solved by an
instruction scheduler.  For a better solution to this problem, the
instruction scheduler has to have an adequate description of the
processor parallelism (or <em class="dfn">pipeline description</em>).  GCC
machine descriptions describe processor parallelism and functional
unit reservations for groups of instructions with the aid of
<em class="dfn">regular expressions</em>.
</p>
<p>The GCC instruction scheduler uses a <em class="dfn">pipeline hazard recognizer</em> to
figure out the possibility of the instruction issue by the processor
on a given simulated processor cycle.  The pipeline hazard recognizer is
automatically generated from the processor pipeline description.  The
pipeline hazard recognizer generated from the machine description
is based on a deterministic finite state automaton (<abbr class="acronym">DFA</abbr>):
the instruction issue is possible if there is a transition from one
automaton state to another one.  This algorithm is very fast, and
furthermore, its speed is not dependent on processor
complexity<a class="footnote" id="DOCF7" href="#FOOT7"><sup>7</sup></a>.
</p>
<a class="index-entry-id" id="index-automaton-based-pipeline-description-1"></a>
<p>The rest of this section describes the directives that constitute
an automaton-based processor pipeline description.  The order of
these constructions within the machine description file is not
important.
</p>
<a class="index-entry-id" id="index-define_005fautomaton"></a>
<a class="index-entry-id" id="index-pipeline-hazard-recognizer-1"></a>
<p>The following optional construction describes names of automata
generated and used for the pipeline hazards recognition.  Sometimes
the generated finite state automaton used by the pipeline hazard
recognizer is large.  If we use more than one automaton and bind functional
units to the automata, the total size of the automata is usually
less than the size of the single automaton.  If there is no one such
construction, only one finite state automaton is generated.
</p>
<div class="example smallexample">
<pre class="example-preformatted">(define_automaton <var class="var">automata-names</var>)
</pre></div>

<p><var class="var">automata-names</var> is a string giving names of the automata.  The
names are separated by commas.  All the automata should have unique names.
The automaton name is used in the constructions <code class="code">define_cpu_unit</code> and
<code class="code">define_query_cpu_unit</code>.
</p>
<a class="index-entry-id" id="index-define_005fcpu_005funit"></a>
<a class="index-entry-id" id="index-processor-functional-units-1"></a>
<p>Each processor functional unit used in the description of instruction
reservations should be described by the following construction.
</p>
<div class="example smallexample">
<pre class="example-preformatted">(define_cpu_unit <var class="var">unit-names</var> [<var class="var">automaton-name</var>])
</pre></div>

<p><var class="var">unit-names</var> is a string giving the names of the functional units
separated by commas.  Don&rsquo;t use name &lsquo;<samp class="samp">nothing</samp>&rsquo;, it is reserved
for other goals.
</p>
<p><var class="var">automaton-name</var> is a string giving the name of the automaton with
which the unit is bound.  The automaton should be described in
construction <code class="code">define_automaton</code>.  You should give
<em class="dfn">automaton-name</em>, if there is a defined automaton.
</p>
<p>The assignment of units to automata are constrained by the uses of the
units in insn reservations.  The most important constraint is: if a
unit reservation is present on a particular cycle of an alternative
for an insn reservation, then some unit from the same automaton must
be present on the same cycle for the other alternatives of the insn
reservation.  The rest of the constraints are mentioned in the
description of the subsequent constructions.
</p>
<a class="index-entry-id" id="index-define_005fquery_005fcpu_005funit"></a>
<a class="index-entry-id" id="index-querying-function-unit-reservations"></a>
<p>The following construction describes CPU functional units analogously
to <code class="code">define_cpu_unit</code>.  The reservation of such units can be
queried for an automaton state.  The instruction scheduler never
queries reservation of functional units for given automaton state.  So
as a rule, you don&rsquo;t need this construction.  This construction could
be used for future code generation goals (e.g. to generate
<abbr class="acronym">VLIW</abbr> insn templates).
</p>
<div class="example smallexample">
<pre class="example-preformatted">(define_query_cpu_unit <var class="var">unit-names</var> [<var class="var">automaton-name</var>])
</pre></div>

<p><var class="var">unit-names</var> is a string giving names of the functional units
separated by commas.
</p>
<p><var class="var">automaton-name</var> is a string giving the name of the automaton with
which the unit is bound.
</p>
<a class="index-entry-id" id="index-define_005finsn_005freservation"></a>
<a class="index-entry-id" id="index-instruction-latency-time-1"></a>
<a class="index-entry-id" id="index-regular-expressions-1"></a>
<a class="index-entry-id" id="index-data-bypass"></a>
<p>The following construction is the major one to describe pipeline
characteristics of an instruction.
</p>
<div class="example smallexample">
<pre class="example-preformatted">(define_insn_reservation <var class="var">insn-name</var> <var class="var">default_latency</var>
                         <var class="var">condition</var> <var class="var">regexp</var>)
</pre></div>

<p><var class="var">default_latency</var> is a number giving latency time of the
instruction.  There is an important difference between the old
description and the automaton based pipeline description.  The latency
time is used for all dependencies when we use the old description.  In
the automaton based pipeline description, the given latency time is only
used for true dependencies.  The cost of anti-dependencies is always
zero and the cost of output dependencies is the difference between
latency times of the producing and consuming insns (if the difference
is negative, the cost is considered to be zero).  You can always
change the default costs for any description by using the target hook
<code class="code">TARGET_SCHED_ADJUST_COST</code> (see <a class="pxref" href="Scheduling.html">Adjusting the Instruction Scheduler</a>).
</p>
<p><var class="var">insn-name</var> is a string giving the internal name of the insn.  The
internal names are used in constructions <code class="code">define_bypass</code> and in
the automaton description file generated for debugging.  The internal
name has nothing in common with the names in <code class="code">define_insn</code>.  It is a
good practice to use insn classes described in the processor manual.
</p>
<p><var class="var">condition</var> defines what RTL insns are described by this
construction.  You should remember that you will be in trouble if
<var class="var">condition</var> for two or more different
<code class="code">define_insn_reservation</code> constructions is TRUE for an insn.  In
this case what reservation will be used for the insn is not defined.
Such cases are not checked during generation of the pipeline hazards
recognizer because in general recognizing that two conditions may have
the same value is quite difficult (especially if the conditions
contain <code class="code">symbol_ref</code>).  It is also not checked during the
pipeline hazard recognizer work because it would slow down the
recognizer considerably.
</p>
<p><var class="var">regexp</var> is a string describing the reservation of the cpu&rsquo;s functional
units by the instruction.  The reservations are described by a regular
expression according to the following syntax:
</p>
<div class="example smallexample">
<pre class="example-preformatted">       regexp = regexp &quot;,&quot; oneof
              | oneof

       oneof = oneof &quot;|&quot; allof
             | allof

       allof = allof &quot;+&quot; repeat
             | repeat

       repeat = element &quot;*&quot; number
              | element

       element = cpu_function_unit_name
               | reservation_name
               | result_name
               | &quot;nothing&quot;
               | &quot;(&quot; regexp &quot;)&quot;
</pre></div>

<ul class="itemize mark-bullet">
<li>&lsquo;<samp class="samp">,</samp>&rsquo; is used for describing the start of the next cycle in
the reservation.

</li><li>&lsquo;<samp class="samp">|</samp>&rsquo; is used for describing a reservation described by the first
regular expression <strong class="strong">or</strong> a reservation described by the second
regular expression <strong class="strong">or</strong> etc.

</li><li>&lsquo;<samp class="samp">+</samp>&rsquo; is used for describing a reservation described by the first
regular expression <strong class="strong">and</strong> a reservation described by the
second regular expression <strong class="strong">and</strong> etc.

</li><li>&lsquo;<samp class="samp">*</samp>&rsquo; is used for convenience and simply means a sequence in which
the regular expression are repeated <var class="var">number</var> times with cycle
advancing (see &lsquo;<samp class="samp">,</samp>&rsquo;).

</li><li>&lsquo;<samp class="samp">cpu_function_unit_name</samp>&rsquo; denotes reservation of the named
functional unit.

</li><li>&lsquo;<samp class="samp">reservation_name</samp>&rsquo; &mdash; see description of construction
&lsquo;<samp class="samp">define_reservation</samp>&rsquo;.

</li><li>&lsquo;<samp class="samp">nothing</samp>&rsquo; denotes no unit reservations.
</li></ul>

<a class="index-entry-id" id="index-define_005freservation"></a>
<p>Sometimes unit reservations for different insns contain common parts.
In such case, you can simplify the pipeline description by describing
the common part by the following construction
</p>
<div class="example smallexample">
<pre class="example-preformatted">(define_reservation <var class="var">reservation-name</var> <var class="var">regexp</var>)
</pre></div>

<p><var class="var">reservation-name</var> is a string giving name of <var class="var">regexp</var>.
Functional unit names and reservation names are in the same name
space.  So the reservation names should be different from the
functional unit names and cannot be the reserved name &lsquo;<samp class="samp">nothing</samp>&rsquo;.
</p>
<a class="index-entry-id" id="index-define_005fbypass"></a>
<a class="index-entry-id" id="index-instruction-latency-time-2"></a>
<a class="index-entry-id" id="index-data-bypass-1"></a>
<p>The following construction is used to describe exceptions in the
latency time for given instruction pair.  This is so called bypasses.
</p>
<div class="example smallexample">
<pre class="example-preformatted">(define_bypass <var class="var">number</var> <var class="var">out_insn_names</var> <var class="var">in_insn_names</var>
               [<var class="var">guard</var>])
</pre></div>

<p><var class="var">number</var> defines when the result generated by the instructions
given in string <var class="var">out_insn_names</var> will be ready for the
instructions given in string <var class="var">in_insn_names</var>.  Each of these
strings is a comma-separated list of filename-style globs and
they refer to the names of <code class="code">define_insn_reservation</code>s.
For example:
</p><div class="example smallexample">
<pre class="example-preformatted">(define_bypass 1 &quot;cpu1_load_*, cpu1_store_*&quot; &quot;cpu1_load_*&quot;)
</pre></div>
<p>defines a bypass between instructions that start with
&lsquo;<samp class="samp">cpu1_load_</samp>&rsquo; or &lsquo;<samp class="samp">cpu1_store_</samp>&rsquo; and those that start with
&lsquo;<samp class="samp">cpu1_load_</samp>&rsquo;.
</p>
<p><var class="var">guard</var> is an optional string giving the name of a C function which
defines an additional guard for the bypass.  The function will get the
two insns as parameters.  If the function returns zero the bypass will
be ignored for this case.  The additional guard is necessary to
recognize complicated bypasses, e.g. when the consumer is only an address
of insn &lsquo;<samp class="samp">store</samp>&rsquo; (not a stored value).
</p>
<p>If there are more one bypass with the same output and input insns, the
chosen bypass is the first bypass with a guard in description whose
guard function returns nonzero.  If there is no such bypass, then
bypass without the guard function is chosen.
</p>
<a class="index-entry-id" id="index-exclusion_005fset"></a>
<a class="index-entry-id" id="index-presence_005fset"></a>
<a class="index-entry-id" id="index-final_005fpresence_005fset"></a>
<a class="index-entry-id" id="index-absence_005fset"></a>
<a class="index-entry-id" id="index-final_005fabsence_005fset"></a>
<a class="index-entry-id" id="index-VLIW-1"></a>
<a class="index-entry-id" id="index-RISC-1"></a>
<p>The following five constructions are usually used to describe
<abbr class="acronym">VLIW</abbr> processors, or more precisely, to describe a placement
of small instructions into <abbr class="acronym">VLIW</abbr> instruction slots.  They
can be used for <abbr class="acronym">RISC</abbr> processors, too.
</p>
<div class="example smallexample">
<pre class="example-preformatted">(exclusion_set <var class="var">unit-names</var> <var class="var">unit-names</var>)
(presence_set <var class="var">unit-names</var> <var class="var">patterns</var>)
(final_presence_set <var class="var">unit-names</var> <var class="var">patterns</var>)
(absence_set <var class="var">unit-names</var> <var class="var">patterns</var>)
(final_absence_set <var class="var">unit-names</var> <var class="var">patterns</var>)
</pre></div>

<p><var class="var">unit-names</var> is a string giving names of functional units
separated by commas.
</p>
<p><var class="var">patterns</var> is a string giving patterns of functional units
separated by comma.  Currently pattern is one unit or units
separated by white-spaces.
</p>
<p>The first construction (&lsquo;<samp class="samp">exclusion_set</samp>&rsquo;) means that each
functional unit in the first string cannot be reserved simultaneously
with a unit whose name is in the second string and vice versa.  For
example, the construction is useful for describing processors
(e.g. some SPARC processors) with a fully pipelined floating point
functional unit which can execute simultaneously only single floating
point insns or only double floating point insns.
</p>
<p>The second construction (&lsquo;<samp class="samp">presence_set</samp>&rsquo;) means that each
functional unit in the first string cannot be reserved unless at
least one of pattern of units whose names are in the second string is
reserved.  This is an asymmetric relation.  For example, it is useful
for description that <abbr class="acronym">VLIW</abbr> &lsquo;<samp class="samp">slot1</samp>&rsquo; is reserved after
&lsquo;<samp class="samp">slot0</samp>&rsquo; reservation.  We could describe it by the following
construction
</p>
<div class="example smallexample">
<pre class="example-preformatted">(presence_set &quot;slot1&quot; &quot;slot0&quot;)
</pre></div>

<p>Or &lsquo;<samp class="samp">slot1</samp>&rsquo; is reserved only after &lsquo;<samp class="samp">slot0</samp>&rsquo; and unit &lsquo;<samp class="samp">b0</samp>&rsquo;
reservation.  In this case we could write
</p>
<div class="example smallexample">
<pre class="example-preformatted">(presence_set &quot;slot1&quot; &quot;slot0 b0&quot;)
</pre></div>

<p>The third construction (&lsquo;<samp class="samp">final_presence_set</samp>&rsquo;) is analogous to
&lsquo;<samp class="samp">presence_set</samp>&rsquo;.  The difference between them is when checking is
done.  When an instruction is issued in given automaton state
reflecting all current and planned unit reservations, the automaton
state is changed.  The first state is a source state, the second one
is a result state.  Checking for &lsquo;<samp class="samp">presence_set</samp>&rsquo; is done on the
source state reservation, checking for &lsquo;<samp class="samp">final_presence_set</samp>&rsquo; is
done on the result reservation.  This construction is useful to
describe a reservation which is actually two subsequent reservations.
For example, if we use
</p>
<div class="example smallexample">
<pre class="example-preformatted">(presence_set &quot;slot1&quot; &quot;slot0&quot;)
</pre></div>

<p>the following insn will be never issued (because &lsquo;<samp class="samp">slot1</samp>&rsquo; requires
&lsquo;<samp class="samp">slot0</samp>&rsquo; which is absent in the source state).
</p>
<div class="example smallexample">
<pre class="example-preformatted">(define_reservation &quot;insn_and_nop&quot; &quot;slot0 + slot1&quot;)
</pre></div>

<p>but it can be issued if we use analogous &lsquo;<samp class="samp">final_presence_set</samp>&rsquo;.
</p>
<p>The forth construction (&lsquo;<samp class="samp">absence_set</samp>&rsquo;) means that each functional
unit in the first string can be reserved only if each pattern of units
whose names are in the second string is not reserved.  This is an
asymmetric relation (actually &lsquo;<samp class="samp">exclusion_set</samp>&rsquo; is analogous to
this one but it is symmetric).  For example it might be useful in a
<abbr class="acronym">VLIW</abbr> description to say that &lsquo;<samp class="samp">slot0</samp>&rsquo; cannot be reserved
after either &lsquo;<samp class="samp">slot1</samp>&rsquo; or &lsquo;<samp class="samp">slot2</samp>&rsquo; have been reserved.  This
can be described as:
</p>
<div class="example smallexample">
<pre class="example-preformatted">(absence_set &quot;slot0&quot; &quot;slot1, slot2&quot;)
</pre></div>

<p>Or &lsquo;<samp class="samp">slot2</samp>&rsquo; cannot be reserved if &lsquo;<samp class="samp">slot0</samp>&rsquo; and unit &lsquo;<samp class="samp">b0</samp>&rsquo;
are reserved or &lsquo;<samp class="samp">slot1</samp>&rsquo; and unit &lsquo;<samp class="samp">b1</samp>&rsquo; are reserved.  In
this case we could write
</p>
<div class="example smallexample">
<pre class="example-preformatted">(absence_set &quot;slot2&quot; &quot;slot0 b0, slot1 b1&quot;)
</pre></div>

<p>All functional units mentioned in a set should belong to the same
automaton.
</p>
<p>The last construction (&lsquo;<samp class="samp">final_absence_set</samp>&rsquo;) is analogous to
&lsquo;<samp class="samp">absence_set</samp>&rsquo; but checking is done on the result (state)
reservation.  See comments for &lsquo;<samp class="samp">final_presence_set</samp>&rsquo;.
</p>
<a class="index-entry-id" id="index-automata_005foption"></a>
<a class="index-entry-id" id="index-deterministic-finite-state-automaton-1"></a>
<a class="index-entry-id" id="index-nondeterministic-finite-state-automaton"></a>
<a class="index-entry-id" id="index-finite-state-automaton-minimization"></a>
<p>You can control the generator of the pipeline hazard recognizer with
the following construction.
</p>
<div class="example smallexample">
<pre class="example-preformatted">(automata_option <var class="var">options</var>)
</pre></div>

<p><var class="var">options</var> is a string giving options which affect the generated
code.  Currently there are the following options:
</p>
<ul class="itemize mark-bullet">
<li><em class="dfn">no-minimization</em> makes no minimization of the automaton.  This is
only worth to do when we are debugging the description and need to
look more accurately at reservations of states.

</li><li><em class="dfn">time</em> means printing time statistics about the generation of
automata.

</li><li><em class="dfn">stats</em> means printing statistics about the generated automata
such as the number of DFA states, NDFA states and arcs.

</li><li><em class="dfn">v</em> means a generation of the file describing the result automata.
The file has suffix &lsquo;<samp class="samp">.dfa</samp>&rsquo; and can be used for the description
verification and debugging.

</li><li><em class="dfn">w</em> means a generation of warning instead of error for
non-critical errors.

</li><li><em class="dfn">no-comb-vect</em> prevents the automaton generator from generating
two data structures and comparing them for space efficiency.  Using
a comb vector to represent transitions may be better, but it can be
very expensive to construct.  This option is useful if the build
process spends an unacceptably long time in genautomata.

</li><li><em class="dfn">ndfa</em> makes nondeterministic finite state automata.  This affects
the treatment of operator &lsquo;<samp class="samp">|</samp>&rsquo; in the regular expressions.  The
usual treatment of the operator is to try the first alternative and,
if the reservation is not possible, the second alternative.  The
nondeterministic treatment means trying all alternatives, some of them
may be rejected by reservations in the subsequent insns.

</li><li><em class="dfn">collapse-ndfa</em> modifies the behavior of the generator when
producing an automaton.  An additional state transition to collapse a
nondeterministic <abbr class="acronym">NDFA</abbr> state to a deterministic <abbr class="acronym">DFA</abbr>
state is generated.  It can be triggered by passing <code class="code">const0_rtx</code> to
state_transition.  In such an automaton, cycle advance transitions are
available only for these collapsed states.  This option is useful for
ports that want to use the <code class="code">ndfa</code> option, but also want to use
<code class="code">define_query_cpu_unit</code> to assign units to insns issued in a cycle.

</li><li><em class="dfn">progress</em> means output of a progress bar showing how many states
were generated so far for automaton being processed.  This is useful
during debugging a <abbr class="acronym">DFA</abbr> description.  If you see too many
generated states, you could interrupt the generator of the pipeline
hazard recognizer and try to figure out a reason for generation of the
huge automaton.
</li></ul>

<p>As an example, consider a superscalar <abbr class="acronym">RISC</abbr> machine which can
issue three insns (two integer insns and one floating point insn) on
the cycle but can finish only two insns.  To describe this, we define
the following functional units.
</p>
<div class="example smallexample">
<pre class="example-preformatted">(define_cpu_unit &quot;i0_pipeline, i1_pipeline, f_pipeline&quot;)
(define_cpu_unit &quot;port0, port1&quot;)
</pre></div>

<p>All simple integer insns can be executed in any integer pipeline and
their result is ready in two cycles.  The simple integer insns are
issued into the first pipeline unless it is reserved, otherwise they
are issued into the second pipeline.  Integer division and
multiplication insns can be executed only in the second integer
pipeline and their results are ready correspondingly in 9 and 4
cycles.  The integer division is not pipelined, i.e. the subsequent
integer division insn cannot be issued until the current division
insn finished.  Floating point insns are fully pipelined and their
results are ready in 3 cycles.  Where the result of a floating point
insn is used by an integer insn, an additional delay of one cycle is
incurred.  To describe all of this we could specify
</p>
<div class="example smallexample">
<pre class="example-preformatted">(define_cpu_unit &quot;div&quot;)

(define_insn_reservation &quot;simple&quot; 2 (eq_attr &quot;type&quot; &quot;int&quot;)
                         &quot;(i0_pipeline | i1_pipeline), (port0 | port1)&quot;)

(define_insn_reservation &quot;mult&quot; 4 (eq_attr &quot;type&quot; &quot;mult&quot;)
                         &quot;i1_pipeline, nothing*2, (port0 | port1)&quot;)

(define_insn_reservation &quot;div&quot; 9 (eq_attr &quot;type&quot; &quot;div&quot;)
                         &quot;i1_pipeline, div*7, div + (port0 | port1)&quot;)

(define_insn_reservation &quot;float&quot; 3 (eq_attr &quot;type&quot; &quot;float&quot;)
                         &quot;f_pipeline, nothing, (port0 | port1))

(define_bypass 4 &quot;float&quot; &quot;simple,mult,div&quot;)
</pre></div>

<p>To simplify the description we could describe the following reservation
</p>
<div class="example smallexample">
<pre class="example-preformatted">(define_reservation &quot;finish&quot; &quot;port0|port1&quot;)
</pre></div>

<p>and use it in all <code class="code">define_insn_reservation</code> as in the following
construction
</p>
<div class="example smallexample">
<pre class="example-preformatted">(define_insn_reservation &quot;simple&quot; 2 (eq_attr &quot;type&quot; &quot;int&quot;)
                         &quot;(i0_pipeline | i1_pipeline), finish&quot;)
</pre></div>


</div>
<div class="footnotes-segment">
<hr>
<h4 class="footnotes-heading">Footnotes</h4>

<h5 class="footnote-body-heading"><a id="FOOT7" href="#DOCF7">(7)</a></h5>
<p>However, the size of the automaton depends on
processor complexity.  To limit this effect, machine descriptions
can split orthogonal parts of the machine description among several
automata: but then, since each of these must be stepped independently,
this does cause a small decrease in the algorithm&rsquo;s performance.</p>
</div>
<hr>
<div class="nav-panel">
<p>
Previous: <a href="Delay-Slots.html">Delay Slot Scheduling</a>, Up: <a href="Insn-Attributes.html">Instruction Attributes</a> &nbsp; [<a href="index.html#SEC_Contents" title="Table of contents" rel="contents">Contents</a>][<a href="Option-Index.html" title="Index" rel="index">Index</a>]</p>
</div>



</body>
</html>
